外观
附录 D 专家助手与团队模板速查表
11 位内置专家决定"谁来干"，3 套团队模板决定"几个人怎么配合干"。这一页是选人和组队的查询台。
D1 按场景找专家
| 我要做的事 | 派哪位专家 | 关键提示 |
|---|---|---|
| 定需求、排优先级、做取舍 | 🧭 manager（产品经理 Alex） | 适合"要不要做"而非"怎么做" |
| 系统设计、技术选型 | 🏛️ software-architect | 会输出权衡矩阵与 ADR |
| 服务端设计、性能与安全 | ⚙️ backend-architect | 关注可扩展性与数据库 |
| 写有质感的 Web 实现 | 👨💻 senior-developer | Laravel / Livewire / FluxUI |
| 审 PR、查安全与性能 | 👀 code-reviewer | 关注正确性而非格式 |
| 上线前验收、挑刺 | 🎯 reality-checker | 要证据，拒绝幻想式审批 |
| 快速验证想法、出 MVP | ⚡ rapid-prototyper | 几天内出可运行方案 |
| 用户研究、可用性验证 | 🔍 ux-researcher | 出方法论与研究结论 |
| 多平台内容创作 | ✍️ content-creator | 公众号/知乎/小红书/B站/X |
| 短视频脚本、投放 | 🎵 douyin-strategist | 关注完播率与 DOU+ |
| 跨平台品牌策略 | 📱 social-media-strategist | LinkedIn / X 一致性 |
D2 11 位内置专家完整表
| 专家 | 定位 | 最该派给他的活 |
|---|---|---|
manager | 资深产品经理（10 年+，B2B SaaS / 消费级 / 平台） | 需求定义、优先级、路线图、干系人沟通、"不做"决策 |
software-architect | 软件架构师（限界上下文、权衡矩阵、ADR） | 系统设计、技术选型、架构决策记录 |
backend-architect | 后端架构师（可扩展、数据库、云基础设施） | 服务端设计、性能与安全、大规模负载 |
senior-developer | 高级开发者（Laravel / Livewire / FluxUI） | 高质量 Web 实现、像素级还原 |
code-reviewer | 代码审查员 | PR 审查：正确性、安全性、可维护性、性能 |
reality-checker | 现实检验者 | 上线前验收：要求压倒性证据 |
rapid-prototyper | 快速原型师 | MVP、概念验证 |
ux-researcher | UX 研究员 | 用户行为、研究方法论、可用性验证 |
content-creator | 内容创作者 | 多平台内容生产 |
douyin-strategist | 抖音策略师 | 短视频脚本、直播、投放 |
social-media-strategist | 社交媒体策略师 | 跨平台布局与品牌一致性 |
D2.1 三种典型"人格设计"（写自定义专家时值得借鉴）
| 专家 | 设计要点 | 一句话 |
|---|---|---|
reality-checker | 主动对抗乐观偏差 | "阻止幻想式审批，生产认证前要压倒性证据" |
manager | 用结果而非产出思考 | "发布了但没人用的功能，只是带部署时间戳的浪费" |
code-reviewer | 明确划出不关心的事 | "关注真正重要的东西，而不是 Tab 和空格之争" |
启示：好的专家规则里，"不做什么"和"要做什么"同样重要。
D3 三套团队模板对照
| 模板 | 分类 | 难度 | 角色 | 步骤 | 适合 |
|---|---|---|---|---|---|
| 软件开发标准流程 | 通用 | 进阶 | 5 | 5 | 正经交付一个软件功能 |
| 一人公司·做内容 | 通用 | 进阶 | 5 | 5 | 个人/小团队做内容运营 |
| Codex + Claude Code 协作编程（极简版） | 开发 | 中级 | 3 | 3 | 快速验证技术想法 |
D3.1 软件开发标准流程
| 步 | 步骤码 | 角色 | 产出 outputKey | 依赖 |
|---|---|---|---|---|
| 1 | clarify | 📦 产品经理 | spec（需求规格） | — |
| 2 | design | 🏛️ 软件架构师 | plan（技术方案） | clarify |
| 3 | implement | 👨💻 高级开发者 | code（代码） | design |
| 4 | review | 👀 代码审查员 | review（审查意见） | implement |
| 5 | verify | 🎯 现实检验者 | acceptance（验收结论） | review |
特点：支持把产出落地为真实文件（materialize）。
D3.2 一人公司·做内容
| 步 | 步骤码 | 角色 | 产出 |
|---|---|---|---|
| 1 | ceo_position | 🧭 老板 / CEO | 内容定位 |
| 2 | audience | 🔍 用户研究员 | 受众洞察 |
| 3 | topics | ✍️ 内容策划 | 选题清单 |
| 4 | script | 🎵 编导 | 脚本 |
| 5 | calendar | 📱 运营 | 发布日历 |
特点：支持变量注入（启动时填一句内容方向，贯穿全流程）；并发度 2。
D3.3 Codex + Claude Code 协作编程（极简版）
| 步 | 步骤码 | 角色 | 任务要点 |
|---|---|---|---|
| 1 | plan | ⚙️ 后端架构师 | 技术规划：思路、模块拆分、验收标准（输入 |
| 2 | implement | ⚡ 快速原型师 | 严格按规划实现（输入 |
| 3 | review | 🎯 现实检验者 | 对照验收标准复核（输入 |
D4 模板编排字段速查
| 字段 | 作用 | 示例 |
|---|---|---|
outputKey | 本步骤产出的名字 | plan_doc、code |
dependsOn | 要等哪些步骤完成 | ["plan"] |
dependsMode | 依赖满足方式 | all |
maxIterations | 最大重试次数 | 1 |
concurrency | 工作流内并发 | 按模板设定 |
maxConcurrent | 团队整体并发上限 | 如 2 |
| 你启动时填的变量 | 需求描述 |
| 前面步骤的产出 | 自动注入 |
两种变量的区别是理解模板的关键：前者让模板通用，后者让步骤接力。
D5 自定义专家骨架
markdown
# {专家名称}
你是**{角色名}**，一位{背景描述，越具体越好}。
## 你的身份与记忆
- **角色**：你负责什么
- **性格**：你优先保证什么、厌恶什么
- **记忆**：你记住哪些模式、哪些坑
- **经验**：你做过什么、见过什么失败
## 核心能力
- 能力 1：具体到可执行
- 能力 2
## 工作方式
- 收到任务先做什么
- 输出用什么结构
- 什么情况下必须停下来问
## 不要做什么
- {明确划出边界}三条写作建议：写"经验"不写"职责"；写"不要做什么"；写清"输出结构"。
写不出来就把岗位描述和工作习惯讲给我，我来蒸馏成规则文件。
D6 什么时候用专家、什么时候用模板
| 你的情况 | 用什么 |
|---|---|
| 需要一个专业视角 | 单个专家 |
| 需要多角度评审 | 多个专家依次发言（会议式） |
| 周期性 + 多角色 + 固定交付物 | ✅ 团队模板 |
| 一个人反复做的动作 | Skill（第 17 章） |
口诀：一个人反复做 → Skill；一队人按顺序做 → 团队模板。
D7 一句话调用模板
【单专家】用{专家名}的视角，帮我看一下{任务}
【多专家】先让{专家A}分析{方面}，再让{专家B}给出{方案}，最后让现实检验者挑刺
【写实检查】让现实检验者审一遍这个方案，指出最可能出问题的地方
【团队模板】用"软件开发标准流程"帮我做一个{功能}
【内容团队】用"一人公司·做内容"，方向是{一句话方向}
【极速验证】用"Codex + Claude Code 协作编程"，需求是{需求}
【自定义专家】按 D5 骨架帮我写一个"{岗位}"专家规则提示：内置专家与模板会随平台版本更新。你自建的那一位，才是真正不可替代的资产。